1. Field of the Invention
This invention is related to the field of virtualization and virtual machines and, more particularly, to virtualization of exception handling.
2. Description of the Related Art
Virtualization has been used in computer systems for a variety of different purposes. For example, virtualization may be used to execute privileged software in a “container” to prevent the privileged software from directly accessing and/or making changes to at least some of the physical machine state without first being permitted to do so by a virtual machine manager (VMM) that controls the virtual machine. Such a container may prevent “buggy” or malicious software from causing problems on the physical machine. Additionally, virtualization may be used to permit two or more privileged programs to execute on the same physical machine concurrently. The privileged programs may be prevented from interfering with each other since access to the physical machine is controlled. Privileged programs may include operating systems, and may also include other software which expects to have full control of the hardware on which the software is executing. In another example, virtualization may be used to execute a privileged program on hardware that differs from the hardware expected by the privileged program.
Generally, virtualization of a processor or computer system may include providing one or more privileged programs with access to a virtual machine (the container mentioned above) over which the privileged program has full control, but the control of the physical machine is retained by the VMM. The virtual machine may include a processor (or processors), memory, and various peripheral devices that the privileged program expects to find in the machine on which it is executing. Each privileged program (and related software in some cases, such as the applications that execute on an operating system) may be referred to herein as a guest. Virtualization may be implemented in software (e.g. the VMM mentioned above) without any specific hardware virtualization support in the physical machine on which the VMM and its virtual machines execute. However, virtualization may be simplified and/or achieve higher performance if some hardware support is provided.
Processors that implement the x86 instruction set architecture (also referred to as the IA-32 instruction set architecture) support a mode of handling floating point exceptions that relies on circuitry external to the processor and a pair of signals exchanged between the external circuitry and the processor. The external circuitry is well defined in the personal computer platform (that is, the external circuitry behaves in the same fashion from implementation to implementation).
Generally, the above mode was provided in x86 processors because the floating point unit (FPU) was originally a separate integrated circuit chip from the processor (sometimes referred to as x87). Accordingly, communication between the processor and the FPU was relatively slow, as compared to intrachip communication. A “delayed” floating point exception mechanism was therefore implemented: a floating point (FP) operation that experiences an FP exception does not signal that exception to the processor immediately. Instead, the next FP operation that the processor attempts to provide to the FPU raises the exception.
Since the processor and the FPU were originally on separate chips, a signalling mechanism was needed to permit the FPU to request an FP exception. The following mechanism was used: When the processor attempts to deliver another FP operation after the FP operation that causes an exception, the FPU refused to accept it, which effectively “freezes” the processor. The FPU also asserted an “FERR” signal. Originally, the FERR signal was wired to the “NMI” (non-maskable interrupt) input pin on the processor. So the FPU's assertion of FERR would cause an NMI in the processor, and the NMI handler would take care of the FP exception.
Typically, the NMI handler would clear FP exceptions in the FPU (thus making the FPU deassert FERR) and either abort or resume the program. However, in some cases, the NMI handler accessed the FPU before clearing the FP exception. Without dismissing the FPU exception first, another FPU operation would freeze the processor again. An ignore numeric error (IGNNE) input signal was added to the processor, which caused the processor to ignore the asserted FERR (and not freeze the processor). An OUT instruction was used by the NMI handler to communicate with external circuitry to cause the IGNNE signal assertion. Deassertion of the FERR signal caused the IGNNE signal to deassert.
Later, the FPU was integrated with the processor on the same chip (beginning with the 80486). Thus, the interchip communication mechanism became unnecessary. However, for compatibility reasons, the functionality was retained. In some later processors, a mode was provided in which the FERR signal and the IGNNE signal were emulated internally, storing corresponding bits in registers accessible to processor hardware. The FERR signal asserted by the processor was stored in a register, and the IGNNE signal was emulated by detecting the OUT instruction mentioned above (which addressed a specific, well known port number F0). When the OUT instruction was detected, the IGNNE bit was placed in the asserted state. The emulation also included placing the IGNNE bit in the deasserted state upon deassertion of the FERR signal/bit.
Virtualizing the FERR/IGNNE mechanism is desirable to support virtualization of x86 processors.